OpenEdge Development:<br />Progress Dynamics Advanced Development SmartObject table

The ryc_smartobject table has a record for every application element that can be considered an object. This includes SmartObjects, DataFields (the Repository’s record of database fields from the application), and procedure files that are in any way maintained or controlled through the framework.

In the case of dynamic SmartObjects, every piece of information about the object definition is stored in the Repository, and its ryc_smartobject record acts as a header for all those other related records. In the case of procedures, they can be registered in the Repository so that they can be related to other objects.

Procedural objects have a SmartObject record and possibly other related records for security or other purposes, but their definition is largely in the 4GL source code in the procedure itself. Procedures that must be registered in the Repository include:

Business logic procedure (PLIPs) that are run in the application.

Procedures that are run as the action of some menu or toolbar item.

SmartObject class super procedures such as smart.p logic procedures for SDOs.

Custom super procedures for dynamic objects.

Because the table holds information for many kinds of objects, not all of its fields are meaningful or used for all objects.

Objects must be assigned an object type and belong to a product module. This facilitates setting up security based on object types and modules, rather than having to secure every object individually.

The SmartObject table supports both physical (static) and logical (dynamic) objects. If the SmartObject itself is a physical, procedural object, then the link to the physical object in the SmartObject record (the field physical_smartobject_obj) is set to 0. This is because a static SmartObject does not require another procedure to realize it at run time. If it is a dynamic object, then the link to the physical object points to the procedure to use as the starting point when instantiating the dynamic object at run time. In other words, a logical object, such as a SmartDataBrowser, is represented by a record in this table whose physical_object_obj value points to the procedure responsible for instantiating all dynamic SmartDataBrowsers.

If the object is flagged as a generic_object, that is, a physical object that is the driver for a class of dynamic objects, then no security allocations, menus, etc. can be allocated to it, as it is useless without the dynamic portions being built first against the logical objects that use it.

The name of the object is stored in the object_filename field. Note that this is a bit of a misnomer, since most objects in this table are not files on disk at all. For logical objects, the object name is specified without a file extension, and the path is not relevant. For procedural objects, the name might or might not include the filename extension, depending on how the procedure is registered. Logic procedures created by the Object Generator, for example, do not have the .p extension as part of the object name. Procedures that are registered through the AppBuilder, using its File

Register In Repository option, do have the extension as part of the object_filename. In either case, the extension for a procedure is also stored in a separate field. The object_path field provides the relative pathname information to locate the object.

All objects have an object_type_obj. This points to the definition of the object type in the gsc_object_type table. Security allocations can be defined against an object type so that they apply to all objects of that type without each individual object needing a security allocation. Object types are also used to define default values for many object attributes or properties, which are inherited by every object of that type that is created.

The ryc_smartobject table contains object IDs pointing to its layout, its object type, its product_module, another object that it can be run by, and if this object displays data for an SDO, its related sdo_snartibhect. This table contains the following fields:

object_filename — This CHARACTER field is either the physical filename (with or without extension) of a static object or the logical name of a dynamic object. It is important to note that the object_filename by itself is not a unique key for the SmartObject table. If an object has customizations, which basically means special attribute values for a particular user, UI Type, or other situation, then there will be multiple SmartObject records with the same object_filename. The primary record, which links to all of the default attributes for the object, will have a customization_result_obj of 0. Other records will have the same object_filename along with a customization_result_obj pointing to a record in the customization_result table. Therefore, you must include the qualifier AND customization_result_obj = 0 in any query against the SmartObject table if you want to retrieve only the primary record for the object. See the separate description of customization support for more information.

object_description — This CHARACTER description is used as the default for a menu label.

static_object — This LOGICAL field indicates whether the object is static or dynamic. Static objects are registered in the Repository so that they can be used as instances within smart containers. Dynamic objects exist in the Repository so that they can be constructed at run time.

system_owned — If this LOGICAL field is set to YES, then the SmartObject record can only be modified by users with a system-owned flag. This field occurs in many tables throughout the Repository to safeguard basic records without which the framework or an application cannot function properly.

shutdown_message_text — This message text is displayed if the user attempts to close down this object while it contains unsaved changes.

template_smartobject — If this LOGICAL field is set to YES, then this SmartObject can be used as a template for creating other similar SmartObjects. This makes it easy to define standard containers, such as a window with a standard toolbar, a standard browser, or a standard layout, and to create new objects based on this template.

object_path — This CHARACTER field is the relative file system path to the object. This must contain forward slashes for portability. A relative path should always be used rather than an absolute path. The path must be relative to the workspace root directory. Because this path is stored in the Repository, it is never necessary to identify a procedure within the Repository by including its relative path; the object name will suffice. For example, when you associate a custom super procedure with a dynamic object, you simply provide its name, which the tools verify is the name of a registered procedure. At run time, the framework constructs the full pathname by prepending the object_path to the object_filename, in order to run the procedure.

object_extension — This CHARACTER field holds the filename extension for a procedure file, such as .p or .w. This is true whether the object_filename has the extension as part of the name or not. The framework uses this to construct the full filename at run time.

container_object — If this LOGICAL field is set to YES, this object is a container window. Only container windows can appear on menus, and only container windows can have a dynamic menu structure.

generic_object — If this LOGICAL field is set to YES, this is a physical generic object used as the starting point for building a dynamic object and is not a complete object in itself. For example, the procedure rydyncontw.w is the procedure that is used to create all dynamic windows at run time. This is registered in the Repository as a generic object, and every other SmartObject that is itself a dynamic window points to this record as its physical_smartobject_obj.

required_db_list — This CHARACTER field is a comma-delimited list of logical database names that must be connected in order to run this object. If any databases are specified and the databases are not connected, then the program is prevented from running, and the menu option/buttons it appears on are disabled, etc.

runnable_from_menu — If this LOGICAL field is set to YES, this object can be run from a menu. Objects such as browsers and viewers cannot be run on their own from a menu. Object controllers and menu controllers can always be run from the menu. Smart windows can sometimes be run from a menu, depending on whether they maintain a specific record or not, that is, whether they are dependent windows that require a key to be passed to them as input. If this flag is set to NO, this object cannot be placed on a menu or dynamic toolbar.

disabled — If this LOGICAL field is set to YES, access to this object is disabled, regardless of any other security settings.

run_persistent — If this LOGICAL field is set to YES, this object is run persistently. This is used only for static objects.

run_when — This CHARACTER option defines the following circumstances under which this program can be run:

ONE — Only one instance of this program can be run at a time.

NOT — This program can only be run when there is no transaction open.

ANY — This program can be run anytime.

NOR — This program can only be run when no other programs are running. While it is running, no other programs can be started.

Note: This field is not yet actively used.

deployment_type — This CHARACTER field holds the deployment type for the specific object. Its value is normally inherited from the gsc_object_type table and the field is described there.

design_only — This LOGICAL field identifies the object as being required only during design or development time. The flag allows the framework to identify which objects to deploy when it is building a run-time-only deployment package that does not require any objects that are used to build the application. The default field value is NO.

custom_smartobject_obj — This DECIMAL field points to a custom super procedure used to provide behavior for a dynamic object. The procedure itself must also be registered in the SmartObject table. This allows its object ID to be stored in this field for each SmartObject it is associated with.

extends_smartobject_obj — This DECIMAL field enables class inheritance for objects so that the actual object super procedure hierarchy can be represented in the Repository, and also so that non-, such as DataFields, can be defined in terms of a hierarchy of domains that define increasingly specific behavior for types of fields. Although this behavior is not yet implemented in Version 2, the Repository structure is present to allow it to be done in a future release.

physical_smartobject_obj — As noted in the description of the generic_object field, some SmartObject records represent the driver procedures that create dynamic objects at run time. If a record represents a dynamic SmartObject, this DECIMAL field holds the object ID of the generic object that realizes it at run time.

security_smartobject_obj — This DECIMAL field is usually the same as the smartobject_obj. It indicates that security is enabled for the object and that this object is used for any security checks. If this field is set to 0, security checking is disabled for this object. A different object can be specified as the security object if this is required to make setting up security restrictions easier. For example, all objects on a container can point at the container object for their security. Possibly an entire suite of objects can point at the same security object, such as the menu.

customization_result_obj — This DECIMAL field can contain the object ID of a record in the customization_result table, and if it is defined, it is combined with the object_filename to identify the SmartObject record for a particular customization of a base SmartObject. This is described in more detail in a separate section on customization.